search

amosjyng / langchain-visualizer

Visualization and debugging tool for LangChain workflows
MIT License
721 stars 52 forks source link

Jupyter proxy support and/or rendering inside a managed Jupyter notebook #59

Open sam-cohan opened 1 year ago

sam-cohan commented 1 year ago

So a very common use case is to try to make use of this tool in a SageMaker notebook environment. As SageMaker notebooks are managed instances, the only way to access the ports is through the jupyter proxy (https:///proxy/8935/). This issue is probably more related to the Ought/ICE code, but I am noticing that it does not work through the proxy: first of all when the page is trying to be loaded the index.html file tries to load assets from https://<notebook_url>/assets/ instead of (https://<notebook_path>/proxy/8935/assets) but even after hard-coding that path and making sure the assets are served, there are internal server errors... I wonder if there is a good way to either fix the proxy compatibility with some sort of patch or better still, force the server visualization to show up in a notebook iFrame instead of a new tab... I know this is probably outside the scope of this project, but it could be an important feature for adoption by many companies that use SageMaker for development purposes. In the absence of such a solution, may have to consider running the server on a separate machine and making sure the messages are routed correctly there, but it is not clear to me that would work since the visualization may require access to the cache and other files generated?

Fulladorn commented 1 year ago

+1 same issue, would be great to have this capability within Sagemaker

amosjyng commented 1 year ago

Ah interesting, thanks for letting me know about your use case! There is already Jupyter support for local instances that renders the result in an iframe, but I have not tried SageMaker and don't know if it will render the page locally before proxying the results. Let me know if you end up trying that iframe method!

I'm guessing fixing this properly would require diving deeper into ICE code, which I plan to do at some point in the future but haven't gotten around to yet.

sam-cohan commented 1 year ago

Yeah unfortunately the iFrame solution still tries to access local host rather than the proxy and thus cannot render the page. I have been digging through it with a colleague and he has a workable solution which involved modifying ICE code. We will clean up the approach and contribute back probably. Do you know if ICE is abandoned? I don't see any activity on there any more. Perhaps we need to maintain our own fork...

amosjyng commented 1 year ago

Oh wow nice!! It seems like they've already responded to https://github.com/oughtinc/ice/pull/306 there, might still be active :P